"Manager"     My very own All-Purpose Utility    by John Collett This is an extension to an article called 'Two ARexx Extensions', in which I described 'ZedREXX' and 'varexx', in favour of the latter. Varexx is 'A GUI system for Arexx'. It is available from aminet/ utils/arexx. Its author is Andrew Cook, and I hope he won't mind me telling you that he can be contacted at : amc93el@soton.ac.uk Here I discuss in some detail my main use of 'varexx'. ------------------- Those of you who are dedicated users of Dir_this, Dir__that, or Dir_the_other will not be persuaded to change your ways by what follows, but those who, like me, love tinkering with ARexx, and who gain some kind of pleasure from designing and using their own tools, may find it a rewarding topic. It is no exaggeration to say that the subject of this article is the most useful day-to-day general purpose tool I have ever had. I've called it 'Manager' - not very original, but a good indication of how I perceive the program. The real satis- faction derives from the fact that I did it all myself (with a little help from my friends), and I can change it at any time and in any way I wish. To move on into the topic, here are brief lists of most of the tools, utilities, etc. which I use with varying frequency.  Day-to-day needs  There are main-line tools regularly in use such as : - A CLI of some sort. I use King-Con. - A text editor. I'm still using QED. - Programs for access to e-mail and internet. - My own daily diary reminder called 'Remind'. Old readers may remember that its features include prodding my memory about today and tomorrow, but doing it only once a day. - A traditional 'dir'-type tool. My favorite is still the small, quick and easy Browser. I hope that in time Manager may take over at least some of its functions. Then there are the tools which I need only from time to time : - DPaintIII - DosMan, for looking up those AmigaDOS details I can never remember. - Findit (a recent internet discovery, handy for locating a file you know you've got but you can't remember where it is). - Palette, and a useful partner, SCR (Screen Color Requester). - Measure, useful for detailed work in planning a graphics layout. - SuperDashBoard, for a quick overview of what's happening behind the scenes. And of course Time, Date, Calculator, IconEdit ...... and there are undoubtedly others that you would include in your own list.  Needs determined by current activities  I usually have one or more pieces of text in hand. Typically they might be : - An article I'm in the process of writing (like this one). - A letter I've started (I'm usually in the middle of one to Peter Bagnato). - Coding for an ARexx program I'm trying to write. - The 'datefile' file for entries I need reminding about. I need not only to be able to launch my editor quickly, but to have it automatically load one or other of these current texts. If that text happens to be intended for MegaDisc, then I like to have a quick way of checking that it will look right when viewed through a text presenter with ANSI capabilities such as FullView (though in fact I use MultiView for these rehearsals). If the text is program code, then from time to time I want to be able to run it instantly, as easily as possible.  Specific needs for 'Manager' development and maintenance  As described below, I need occasionally to be able to run GadToolsBox to edit Manager's window. The copy of Manager used for updating, trials, and general development is held in Work:, but I also have a copy in WBStartup, so that it runs automatically at bootup. So I need an easy way of updating the WBStartup version if changes I have just made are to apply at my next bootup time.  Access to background materials  As well as quick access to current texts or programs, I may need to look up earlier documentation, run some other program, or view an image I have stored somewhere. Ideally, I want to be able to go directly to a particular directory, so that I can then read any text, view any picture, or run any program, with a minimum of trouble.  Organisation of study materials  Sometimes (quite often), for the good of my soul, or because I need it for current computer activities, I have to bite the bullet and settle down to some real learning. Recently, for example, I have been probing RexxReqTools, and learning to use a fairly complex image processor. I thought that if I made access to such tasks very easy, then I would be less likely to procrastinate. And I was right.  What "Manager" provides  I'm sorry if the above list of needs and activites seemed to go on for ever. It was just that I wanted to lay a firm foundation for the following punch-line : When "Manager" is running, everything listed above can be reached by a single button click. Its convenience is of course its main feature, but it is not unique in such a provision. I have achieved similar results (though perhaps not so extensive) using AutoCLI (with support scripts AutoCLI.f1 to .f9, and .e1 to .e9) and ToolManager. Respectively they require two key presses and a menu selection. In a trivial sense, a single mouse click may be easier than either of these, but some people prefer to just point and click whenever possible anyway, and I am one of them. But there is a major difference between 'Manager' and the other two systems just mentioned which makes it my clear favourite. 'Manager' offers a window which acts as a strategic organiser and a permanent prompt. It may not be a work of art, but it nicely iconifies my computing activities, and offers a rare combination of compactness, flexibility, and personalised interface. 'Manager' is run at bootup, and I have available, immediately and permanently, a layout of various gadgets. The critical details - what types of gadgets they are, exactly where they are, and what they do when selected - are my own choice. Each gadget has been added to the set when I felt the need to include it, and the type, position, or task of any gadget can be changed at any time. It's great. Doesn't it ever get in the way? No, but if you do want to clear the space, there is a zoom gadget which reduces the window to an icon into the title bar, though I rarely feel the need to use this. This feature can also be invoked from within a script with the command 'window ZIP'.  How it works in general  Gui files are created by using GadToolsBox, and saved. The gadgets which can be inserted into such files include the following types, all of which are now supported by varexx : GETFILE To enable the user to select a file/dir/volume name. BUTTON To trigger a program action. CHECKBOX To switch program options on or off. INTEGER To obtain numeric values from the user. LISTVIEW To display a list of textual names. MX To let the user select one out of several possibilities (I thought these were usually called 'radio buttons'). NUMBER A read-only gadget to display a numerical value. CYCLE To let the user select one out of several possibilities. PALETTE To let the user select a colour from a set palette. SCROLLER To adjust the positions of a view, for example scrolling the text up and down in a text editor. SLIDER To select a value within a fixed range, for instance the red, green and blue intensities of a palette editor. STRING Normally used to obtain character strings from the user. TEXT A read only gadget to display a character string. The GadToolsBox program includes heaps of further options via its menus, but few of them are currently relevant to varexx. When each gadget is created, its type, position, and wording (if any) are determined. If it is going to have a job to do, it must be assigned a unique label. Only then can its selection be recognised in any ARexx program which loads in this particular gui file.  How it works in a particular case  Consider this hypothetical sequence : - GadToolsBox opens, and displays a gui window ready for use as a template. - By menu selection, a gadget is inserted in the window.  __________________________________  |__|_________________________|__|__| | | |  __________________  | | | | | | | Sample gadget | | | |__________________| | | | |__________________________________| - A label, say, SAMPGAD, is assigned to the gadget. - You make the window whatever size you want it to be, place it as required, and you can arrange for it to have whatever system gadgets etc. you choose. - The gui is saved. Later, assuming 'varexx' is launched (in the same way as 'rexxmast' must be used before running an ARexx program) : - An ARexx program loads in and displays the gui. - A user clicks on the sample gadget. - The message SAMPGAD is received by the program. - Further coding determines subsequent actions. In this way, I have developed a window with all the gadgets I need. The coding which they invoke in my program does its job, and I have ended up with a pretty useful "All-Purpose Utility".  How "Manager" works in each session  My 'startup-sequence' file has long included 'rexxmast'. Just after that line I have now inserted 'varexx rexx:gui'. So both ARexx and varexx are available in the background, and varexx will use the 'rexx:gui' directory as its default source for all gui files. A copy of the "Manager" program itself (with DONOTWAIT as one of its tool settings) is in the WBStartup directory. It therefore runs automatically at bootup, and is always available. On my first access each day, if I have any social engagements today or tomorrow, I am reminded of them. It's a relatively new toy, and so I change the window frequently, but at the moment it appears at position 160,60, is 350 pixels across by 80, and contains 24 gadgets and a List.  How I make changes  If, for example, I decided that I want to see the date at the beginning of every session, how would I go about it? I could simply click on the 'Date' gadget which is already in the window, but let's say I want it to be displayed automatically. I already know that I am going to keep on changing the contents of my Manager window, so one of my Manager's button gadgets is designed to launch GadToolsBox. Then the dialogue in GadToolsBox goes like this : Open Volumes Rexx: gui/ manager.gui Menu #2 Gadgets Kind Text Click and drag, to place and size the new gadget. Text gadget editor : Text (leave empty; the date will be inserted there later) Label TODAYDATE ('DATE' has already been used) Others ignore Save and Quit Now I have to tell 'Manager' what to do with it. One click opens my text editor and loads 'manager.rexx'. (Oh, the convenience.) The date-display gadget is not intended to be clicked, but just to display the date. We don't require it to send a message, so there is no need to include a 'when class = TODAYDATE' handler. We simply want to set the text displayed in the new gadget to today's date as soon as the window is opened. All it needs is a brief insertion after 'show' : show /* Displays the window */ 'settext TODAYDATE 'date() /* Inserts today's date in the gadget labelled TODAYDATE */ (By the way, it's worth mentioning here that some of the 'set' commands have to be given before the window is diplayed by the 'show' command. 'Settext' is not one of them.) Let's now stay with this idea, just to indicate the direction to be taken if something less trivial is to be inserted - though the example I'm using is actually a silly one. If instead of selecting Menu_2/Kind/Text we go for Menu_2/Kind/String, we make a gadget the contents of which can be changed by a user. Just to demonstrate how it works, we'll have the date displayed as before, and then shout at a user who tries to change it. We'll give this gadget the label DATESTRING. The line 'settext DATESTRING 'date() will have the same effect as 'settext TODAYDATE 'date(), but it will be able to detect and respond to user input. On any such input, the message sent to the program will be DATESTRING and the output from date(), so some parsing is necessary using word(). The coding looks like this : when word(class,1) = 'DATESTRING' then do  msg = "You fool! Stop trying to change today's date." ,  '0a'x || "Such things are beyond human control." call message (msg) end In its turn the message procedure uses the RexxReqTools rtezrequest() function : message : procedure call rtezrequest( arg(1),'Okay','A Message',, 'rt_reqpos = reqpos_topleftscr rtez_flags=ezreqf_centertext',) return If you tried to change the contents of this gadget, you would see :  _________________________________________________  | A Message ___________________________________|__| | _______________________________________________ | || You fool! Stop trying to change today's date. || || Such things are beyond human control. || ||_______________________________________________|| | | Okay | | |_________________________________________________| So that's how gadgets are added, and how they can determine subsequent actions. Immediately after such editing, I want to quit and restart Manager to see the effects of any changes. Easy. As well as 'Manager.rexx' in my Work: directory, and a copy in WBStartup, I also have a 'Manager' icon 'left out' on my Workbench screen, so restarting it is just a matter of a couple of clicks.  Examples of gadget planning strategies  I mentioned above the need for quick access to background materials - document, picture, and program collections. Here I'll discuss briefly some good and some not so good ways in which this could be approached. They serve as illustrations of some of the types of gadgets available (though I cannot reproduce the graphics elements here).  1  Three file-selector gadgets __ Texts | | In each box there is |__| a file selector symbol Pix | | which I have given up |__| trying to reproduce here. Progs | | |__| They work perfectly; clicking on any one takes you straight to a target directory.  2  An MX (radio button) gadget _ _ (*) Texts (*) Texts (_) Pix (_) Pix (_) Progs (_) Progs (_) Coding handles the outcome of actions, and clicking on a button opens a file requester as required. I have tried the arrangement on the left, but met the problem that one of the choices must always be 'on'. It worked better with a dummy ('None of these') button as shown here on the right. Program coding resets the flag to the dummy after any of the real ones have been used. It works, but this type of gadget is not the best for this particular job.  3  A CYCLE gadget As you click it, it displays  ___________ __________ __________   |@|Read text| or |@|Show pic| or |@|Run prog| where '@' stands for the circular arrow thingy. When it matches your  __  intention, you click on an accompanying [Ok]. It does work, and is economical on space, but is not particularly elegant for this specific task.  4  A List gadget The list gadget turns out to be one of the most interesting features. List items can of course be selected by a user. That's why they're there. But items can also be added, cleared, selected, etc. from within the ARexx program itself, which makes it a powerful way of changing the available range of options while a program is running. One aspect of this is particularly interesting. If you create even just a token and initially empty list gadget for your varexx window via GadToolsBox, you can then add as many items to it as you like. The actions subsequent upon their selection can be determined by coding, and thus a large range of options can be made available without having to run GadToolsBox again (not that that in itself is any problem, of course). The appearance of lists can thus change radically :  ______________ _______________ ______________  |Read Text | | | Monday | | |Editor | | |View Pix | | | Tuesday | | |DPaint | | |Run Progs | | > | Wednesday | | > |Calculator | | | | | | Thursday | | |IconEdit | | | | | | Friday | | |etc | | |____________|_| |_____________|_| |____________|_| All the action re-settings would be done within the parent ARexx program (though I have made little use of this technique within Manager itself). I'm not going to spell out the potential which this holds, but believe me, it astonished me when I first used it, and I'm still getting more ideas about ways in which I might use it. The List gadget currently in my Manager window is definitely going to assume a major role. Just think of the possibilities when the items of the list are read in from a plain text file and the coding for each of them can be tailored to do practically any job.  Oh, and there are lots more .....  .... interesting features of 'varexx', many of which I have used, and I'm certain there are also many more which I have still to discover.  On-going developments of 'varexx'  While I was writing this, at the beginning of February, 1996, I received email from Andrew Cook telling me that version 1.6 of varexx had just been posted to aminet. I down-loaded it, and started using it at once. Great. Andrew also tells me that a 'major rewrite with many new features' is in the pipeline. Great! Hamilton, New Zealand February, 1996 ---------------------------